In the past couple of years there has been an explosive growth in the Internet, and in particular of the World-wide Web (WWW or Web), which is one of the facilities provided on top of the Internet. The WWW comprises many pages or files of information, distributed across many different servers. Each page is identified by a Universal Resource Locator (URL). The URL denotes both the server machine, and the particular file or page on that machine. There may be many pages or URLs resident on a single server.
In order to use the WWW, a client runs a piece of software known as a Web browser, such as WebExplorer (provided as part of the Operating System/2 (OS/2).COPYRGT. IBM Corporation), or the Navigator (.COPYRGT.) program available from Netscape Communications Corporation. The client interacts with the browser to select a particular URL, which in turn causes the browser to send a request for that URL or page to the server identified in the URL. Typically the server responds to the request by retrieving the requested page, and transmitting the data for that page back to the requesting client (the client server interaction is performed in accordance with the hypertext transport protocol ("HTTP")). This page is then displayed to the user on the client screen. The client may also cause the server to launch an application, for example to search for WWW pages relating to particular topics.
Most WWW pages are formatted in accordance with a language known as HTML (hypertext mark-up language). Thus a typical page includes text together with embedded formatting commands, referred to as tags, which can be used to control the font size, the font style (for example, whether italic or bold), how to lay-out the text, and other page options. A Web browser parses the HTML script in order to display the text in accordance with the specified format. In addition, an HTML page can also contain a reference, in terms of another URL, to a piece of multimedia data, for example, an image, a video segment, or an audio file. A Web browser responds to such a reference by retrieving and displaying or playing the data. Alternatively, such multimedia data may form its own WWW page, without any surrounding HTML text.
Most WWW pages also contain one or more references to other WWW pages, which need not be on the same server as the original page. Such references may generally be activated by the user selecting particular locations on the screen, typically by (double) clicking a mouse control button. These references or locations are known as hyperlinks, and are typically flagged by the browser in a particular manner (for example, any text associated with a hyperlink may be in a different color). If a user selects the hyperlink, then the referenced page is retrieved and replaces the currently displayed page.
Further information about HTML and the WWW can be found in "World Wide Web and HTML" by Douglas McArthur, p18-26 in Dr Dobbs Journal, December 1994, and in "The HTML SourceBook" by Ian Graham, (John Wiley, New York, 1995).
As so far described, and broadly speaking as currently implemented, the WWW suffers from the disadvantage that pages downloaded from a server to a client are essentially passive, in other words, they do not contain code which is executed at the client machine. One implication of this is that the server cannot offload onto the client any of the processing associated with the interaction between the client and the server. Thus if the client is completing a form with their telephone number for example, then any formal checks such as to the number of digits in the telephone number must be performed at the server. This results firstly in a heavier processing burden at the server, and secondly in time-consuming extra communications between the server and client should there be any mistakes to correct. Moreover, the inability of the server to download code for execution at the client is a significant limitation on the type of applications that can be created to exploit the WWW.
Recent developments, based particularly on the Java (.COPYRGT. Sun Microsystems, Inc.) technology from Sun Microsystems Inc., have sought to overcome the above difficulties. The Java technology comprises primarily (i) a new programming language, somewhat similar to C and C++, and (ii) a virtual machine. Essentially, programs written in the Java programming language can be compiled into byte code form, and then interpreted at runtime on the Java virtual machine executing on the client. The Java virtual machine converts the byte codes into instructions that can be executed by the underlying physical machine.
Programs written using Java can be downloaded over the WWW in the form of byte codes for execution on a Java virtual machine at the client. Such programs are known as "applets". The use of the Java technology for downloading code over the WWW has two major benefits. Firstly, an applet can be platform independent, if we assume that each client has a copy of the Java virtual machine (the virtual machine at the client's system is typically incorporated either into the operating system, or into the Web browser itself). In other words, there is no need for a server to have different versions of the code for downloading to clients according to their respective operating systems and machines. Therefore, only a single version of the relevant code needs to be written and maintained, which makes life much simpler for software developers.
Secondly, because the applet executes on a virtual machine, rather than a physical machine, security is greatly improved. Thus, when downloading code over the network, there is always a risk that it will include some malicious code (accidentally or otherwise) that may damage data or programs stored at the client. The virtual machine however can monitor the operation of the applet, and so detect and prevent such malicious activity.
It will be noted that the concept of downloading software from a server to a client in the form of byte codes for execution on a virtual machine was also known independently of the Java technology, see for example U.S. Pat. No. 5,347,632.
In order to invoke a Java applet, a Web page of HTML text contains an &lt;APPLET&gt; tag, which identifies the URL containing the applet. A browser responds to this tag by retrieving and running the applet. Also defined is a &lt;PARAM&gt; tag, which is contained within a pair of corresponding &lt;APPLET&gt; and &lt;/APPLET&gt; tags, and which can be used to specify parameters that are passed to the applet at run-time. (Note that the APPLET and PARAM tags are not formally incorporated into the HTML standard, but are nevertheless recognised by many Web browsers). Further information about the Java technology and applets can be found in "Teach Yourself Java in 21 Days" by Laura Lemay and Charles Perkins (Sams.net Publishing, Indianapolis, USA, 1996).
Prior to and in parallel to the WWW advancements described above, separate technologies were being developed to allow workstation access to mainframe data. One such technology which is prevalent in business environments today is terminal emulation (emulator) software which resides on user PCs and provides connectivity to host computers via a variety of networking protocols (e.g. SNA, TCP/IP, etc.). When executed, emulators present an application window similar to early textual mainframe-specific data-stream terminals (e.g. 3270/5250/VT) that allow a user to execute applications residing on the host. Electronic mail is an example of such an application whereby the host stores incoming messages for a user that they can access remotely via an emulator.
Emulators, through the development of Emulator High-Level Language Application Programming Interfaces (EHLLAPI), have become programmable to allow developers to customise their access and manipulation of host data. The programmed interface runs on top of the emulation software on the local workstation, simulates keystrokes against the emulator screen, and copies data to and from it (screen scraping). Because emulators simply relayed text-based output of mainframe applications, EHLLAPI applications were developed that could gather that information and display it in more useable and appealing graphical user interfaces (GUIs). Some implementations also do more than screen scraping and actually manipulate data-streams before they are formatted for screen output. These capabilities are valuable to emulator users who automate repetitive tasks, mask host applications and integrate host information with workstation software. An example of such an EHLLAPI application is a point-and-click front-end GUI that allows users to search a host database that has difficult textual command sequences. The EHLLAPI application can receive input from the user in the form of windowed checkboxes or drop-down list selections and translate that into the textual commands necessary to execute the database query. The results of the query can also be formatted to present the user with a more user-friendly list of results.
The basic Java and emulator functions described above have recently been combined to yield host connectivity without emulator software residing on the user's workstation. Instead, Java emulator applets have been developed that physically reside on a server machine and provide emulator function when accessed via a Java-enabled browser. With this approach, and the proliferation of browsers on user desktops, there is no longer a need to maintain emulator code on each individual machine and client platform. However, the complexity of emulator function and difficulties of maintaining persistent data in Java implementations have limited the capabilities of these Web emulator solutions.
Two key problems that have not been resolved for Web emulators are server platform independence and data-stream access. Current solutions create server platform dependence by using Java to merely extend the display of an emulator application running on the server. Thus, the Java applet must know how the server emulator displays information to parse it properly. With such an approach the solution depends upon running particular server software and loses some independence benefits of Java. In addition, such approaches are limited to screen scraping when interacting with the host. This requires that application developers know the screen format and the sequence of keystrokes necessary to manipulate it. No current Web emulator implementation allows complete server and client platform independence while also providing data-stream access to emulator application developers.